home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 3972 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.9 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Secure from Decompiling??
  5. Date: 31 Jan 1996 06:58:53 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4eo03dINN2b8@keats.ugrad.cs.ubc.ca>
  8. References: <4djaq2$jd5@earth.superlink.net> <310e83a8.14450560@netline-fddi.jpl.nasa.gov>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <310e83a8.14450560@netline-fddi.jpl.nasa.gov>,
  12. Kevin Quitt <kdq@emoryi.jpl.nasa.gov> wrote:
  13. >I'm going to assume this string is a password to allow operation of the
  14. >program.  Any such comparison is easily thwarted by looking for where the
  15. >decision is made based on the comparison, and patching in an absolute jump.
  16. >The only way you can protect your code is to encrypt the code such that only
  17. >the password will properly decrypt the code (in RAM).  Get the password and
  18. >unconditionally decrypt the code.  Now just jump to the code.  It'll either
  19. >work or blow up--not your problem.  If you want to be nice, you can put
  20. >interrupt handlers in to catch the likely errors, and have your code decrypted
  21. >code remove them (but not immediately).
  22. >
  23. >This gives them no information, no shortcuts, and nowhere to trap and restart
  24. >to bypass the test.
  25.  
  26. But you have to distribute the password to legitimate users. The best thing is
  27. to do, if you can, is to make up a new password for each copy of the program.
  28. Of course, if someone wants to crack the program, they just obtain a legit
  29. password and decrypt the code with your own algorithm, be it DES, IDEA or what
  30. have you.
  31.  
  32. On UNIX systems, the superuser can even examine the code of programs that are
  33. running without using any special debugging tools. If I wanted to look for
  34. strings in the program, I'd just to go /proc/<pid>, say, and look at the
  35. virtual file which represents the memory image of the running process.
  36. -- 
  37.  
  38.